Skip to content

CCM-14200 - event driven callback delivery#33

Draft
mjewildnhs wants to merge 83 commits intomainfrom
feature/CCM-14200-event-driven-callback-delivery
Draft

CCM-14200 - event driven callback delivery#33
mjewildnhs wants to merge 83 commits intomainfrom
feature/CCM-14200-event-driven-callback-delivery

Conversation

@mjewildnhs
Copy link
Contributor

Description

Context

Type of changes

  • Refactoring (non-breaking change)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would change existing functionality)
  • Bug fix (non-breaking change which fixes an issue)

Checklist

  • I am familiar with the contributing guidelines
  • I have followed the code style of the project
  • I have added tests to cover my changes
  • I have updated the documentation accordingly
  • This PR is a result of pair or mob programming
  • If I have used the 'skip-trivy-package' label I have done so responsibly and in the knowledge that this is being fixed as part of a separate ticket/PR.

Sensitive Information Declaration

To ensure the utmost confidentiality and protect your and others privacy, we kindly ask you to NOT including PII (Personal Identifiable Information) / PID (Personal Identifiable Data) or any other sensitive data in this PR (Pull Request) and the codebase changes. We will remove any PR that do contain any sensitive information. We really appreciate your cooperation in this matter.

  • I confirm that neither PII/PID nor sensitive data are included in this PR and the codebase changes.

@mjewildnhs mjewildnhs force-pushed the feature/CCM-14200-event-driven-callback-delivery branch from 5dd5607 to c8d84f7 Compare February 18, 2026 11:39
@mjewildnhs mjewildnhs force-pushed the feature/CCM-14200-event-driven-callback-delivery branch 2 times, most recently from 9447393 to c90f89d Compare February 18, 2026 11:52
@mjewildnhs mjewildnhs changed the base branch from main to feature/CCM-14199-foundation February 18, 2026 13:20
@mjewildnhs
Copy link
Contributor Author

@copilot review

Copy link

Copilot AI commented Feb 18, 2026

@mjewildnhs I've opened a new pull request, #34, to work on those changes. Once the pull request is ready, I'll request review from you.

@mjewildnhs mjewildnhs changed the base branch from feature/CCM-14199-foundation to main February 18, 2026 13:24
@mjewildnhs mjewildnhs marked this pull request as ready for review February 18, 2026 13:40
@mjewildnhs mjewildnhs requested review from a team as code owners February 18, 2026 13:40
@mjewildnhs mjewildnhs marked this pull request as draft February 18, 2026 13:41
@mjewildnhs mjewildnhs closed this Feb 18, 2026
@mjewildnhs mjewildnhs reopened this Feb 18, 2026
/**
* Add persistent context that will be included in all subsequent log entries
*/
addContext(context: LogContext): void {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we going to include things like COMPONENT in log context like core does?

const correlationId = extractCorrelationId(rawEvent);
logger.addContext({ correlationId });

logLifecycleEvent("received", {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth "received" and any other events being strongly typed? We could have it so the TypeScript typings apply to the full payload so we can't pass invalid keys for a given event.


// Emit metric for event received
await metricsService.emitEventReceived(
eventType ?? "unknown",

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than having to ?? "unknown" everywhere, it might make sense for the metrics service to do this for us by allowing the property to be undefined and filling it in with the defaults if missing.

await metricsService.emitDeliveryInitiated(clientId || "unknown");

// Clear context for next event
logger.clearContext();

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there ever a chance of the handler being invoked multiple times in succession in the same NodeJS runtime? Considering we're using async / await everywhere, this could lead to the context being cleared before one request fully finishes, as different parts of the code will resume in a non-deterministic order.

We may instead want to have unique elements of the logging context always be passed around in log calls to avoid this situation.

});
await metricsService.emitTransformationFailure(
eventErrorType,
"TransformationError",

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these also might benefit from strong typing

functions: 100,
lines: 100,
statements: -10,
branches: 50,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these thresholds intentional for all work going forwards?

@mjewildnhs mjewildnhs force-pushed the feature/CCM-14200-event-driven-callback-delivery branch from 84de504 to fd433af Compare February 24, 2026 15:06
@mjewildnhs mjewildnhs force-pushed the feature/CCM-14200-event-driven-callback-delivery branch from c412701 to 6287115 Compare February 24, 2026 16:49
rhyscoxnhs
rhyscoxnhs previously approved these changes Feb 26, 2026
Copy link

@rhyscoxnhs rhyscoxnhs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No real fundamental issues here. I've left some minor suggestions for improvements, but there's no need to block a merge for these.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comments added to this file seem fairly redundant, maybe we can strip these out?

variable "deploy_mock_webhook" {
type = bool
description = "Flag to deploy mock webhook lambda for integration testing (test/dev environments only)"
default = true # CCM-14200: Temporary test value, revert to false

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to revert this to false now?

notifyData.supplierStatus.toLowerCase() as ClientSupplierStatus;

const attributes: ChannelStatusAttributes = {
messageId: notifyData.messageId,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can just be messageId, since it's destructured above

);

const attributes: MessageStatusAttributes = {
messageId: notifyData.messageId,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as the other one - this can just be messageId,

level: process.env.LOG_LEVEL || "info",
});

function isValidCallbackPayload(payload: unknown): payload is CallbackPayload {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be easier to understand as a zod schema, it's a bit hard to parse as it is right now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants